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(54) Service delivery method and system 

(57) A user (70) is pre-qualified for a service to be 
provided at a particular location. A service instance el- 
ement (76) is stored as is location data (74) indicative 
of where the service is to be triggered. The service in- 
stance element (76) may be a full customised instance 
of the service delivery code or other item that provides 
an association between the user and an instance of the 
service for which the user has been qualified. Thereaf- 
ter, the location of the user (70), as indicated by a mobile 



entity associated with the user, is periodically checked 
against the location data (74) and when a location match 
is indicated, the service instance (76) for which the user 
has been qualified is executed to deliver the required 
service to the user (70). An example is of an airline trav- 
eller buying an air ticket from a travel agent, the ticket 
having an associated service by which, upon the travel- 
ler arriving at the relevant airport, the traveller is con- 
tacted via his/her mobile device and guided through the 
check-in and boarding processes. 
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Description 

Field of the Invention 

[0001] The present invention relates to the delivery of 
services to mobile users in dependence on the location 
of the users. 

Background of the Invention 

[0002] Communication infrastructures suitable for 
mobile users (in particular, though not exclusively, cel- 
lular radio infrastructures) have now become widely 
adopted. Whilst the primary driver has been mobile te- 
lephony, the desire to implement mobile data-based 
services over these infrastructures, has led to the rapid 
development of data-capable bearer services across 
such infrastructures. This has opened up the possibility 
of many Internet-based services being available to mo- 
bile users. 

[0003] By way of example, Figure 1 shows one form 
of known communication infrastructure for mobile users 
providing both telephony and data-bearer services. In 
this example, a mobile entity 20, provided with a radio 
subsystem 22 and a phone subsystem 23, communi- 
cates with the fixed infrastructure of GSM PLMN (Public 
Land Mobile Network) 1 0 to provide basic voice teleph- 
ony services. In addition, the mobile entity 20 includes 
a data-handling subsystem 25 interworking, via data in- 
terface 24, with the radio subsystem 22 forthe transmis- 
sion and reception of data over a data-capable bearer 
service provided by the PLMN; the data-capable bearer 
service enables the mobile entity 20 to communicate 
with a service system 40 connected to the public Internet 
39. The data handling subsystem 25 supports an oper- 
ating environment 26 in which applications run, the op- 
erating environment including an appropriate communi- 
cations stack. 

[0004] More particularly, the fixed infrastructure 1 0 of 
the GSM PLMN comprises one or more Base Station 
Subsystems (BSS) 11 and a Network and Switching 
Subsystem NSS 12. Each BSS 11 comprises a Base 
Station Controller (BSC) 14 controlling multiple Base 
Transceiver Stations (BTS) 13 each associated with a 
respective "cell" of the radio network. When active, the 
radio subsystem 22 of the mobile entity 20 communi- 
cates via a radio link with the BTS 1 3 of the cell in which 
the mobile entity is currently located. As regards the 
NSS 12. this comprises one or more Mobile Switching 
Centers (MSC) 1 5 together with other elements such as 
Visitor Location Registers 32 and Home Location Reg- 
ister 32. 

[0005] When the mobile entity 20 is used to make a 
normal telephone call, a traffic circuit for carrying digi- 
tised voice is set up through the relevant BSS 11 to the 
NSS 12 which is then responsible for routing the call to 
the target phone (whether in the same PLMN or in an- 
other network). 



[0006] With respect to data transmission to/from the 
mobile entity 20, in the present example three different 
data-capable bearer services are depicted though other 
possibilities exist. A first data-capable bearer service is 

5 available in the form of a Circuit Switched Data (CSD) 
service; in this case a full traffic circuit is used for carry- 
ing data and the MSC 32 routes the circuit to an Inter- 
Working Function IWF 34 the precise nature of which 
depends on what is connected to the other side of the 

10 iwR Thus, IWF could be configured to provide direct 
access to the public Internet 39 (that is, provide func- 
tionality similar to an IAP - Internet Access Provider 
IAP). Alternatively, the IWF could simply be a modem 
connecting to a PSTN; in this case, Internet access can 

*5 be achieved by connection across the PSTN to a stand- 
ard IAP. 

[0007] A second, low bandwidth, data-capable bearer 
service is available through use of the Short Message 
Service that passes data carried in signalling channel 

20 slots to an SMS unit which can be arranged to provide 
connectivity to the public Internet 39. 
[0008] A third data-capable bearer service is provided 
in the form of GPRS (General Packet Radio Service 
which enables IP (or X.25) packet data to be passed 

25 from the data handling system of the mobile entity 20, 
via the data interface 24, radio subsystem 21 and rele- 
vant BSS 11, to a GPRS network 17 of the PLMN 10 
(and vice versa). The GPRS network 1 7 includes a SG- 
SN (Serving GPRS Support Node) 18 interfacing BSC 

30 14 with the network 17, and a GGSN (Gateway GPRS 
Support Node) interfacing the network 17 with an exter- 
nal network (in this example, the public Internet 39). Full 
details of GPRS can be found in the ETSI (European 
Telecommunications Standards Institute) GSM 03.60 

35 specification. Using GPRS, the mobile entity 20 can ex- 
change packet data via the BSS 11 and GPRS network 
17 with entities connected to the public Internet 39. 
[0009] The data connection between the PLMN 10 
and the Internet 39 will generally be through a firewall 

40 35 with proxy and/or gateway functionality. 

[0010] Different data-capable bearer services to 
those described above may be provided, the described 
services being simply examples of what is possible. 
[001 1 ] In Figure 1 , a service system 40 is shown con- 

45 nected to the Internet 40, this service system being ac- 
cessible to the OS/application 26 running in the mobile 
entity by use of any of the data-capable bearer services 
described above. The data-capable bearer services 
could equally provide access to a service system that is 

50 within the domain of the PLMN operator or is connected 
to another public or private data network. 
[0012] With regard to the OS/application software 26 
running in the data handling subsystem 25 of the mobile 
entity 20, this could, for example, be a WAP application 

55 ru nning on top of a WAP stack where "WAP" is the Wire- 
less Application Protocol standard. Details of WAP can 
be found, for example, in the book "Official Wireless Ap- 
plication Protocol" Wireless Application Protocol Forum, 
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Ltd published 1999 Wiley Computer Publishing. Where 
the OS/application software is WAP compliant, the fire- 
wall will generally also serve as a WAP proxy and gate- 
way. Of course, OS/application 26 can comprise other 
functionality (for example, an e-mail client) instead of, 
or additional to, the WAP functionality. 
[001 3] The mobile entity 20 may take many different 
forms. For example, it could be two separate units such 
as a mobile phone (providing elements 22-24) and a mo- 
bile PC (data-handling system 25) coupled by an appro- 
priate link (wireline, infrared or even short range radio 
system such as Bluetooth). Alternatively, mobile entity 
20 could be a single unit such as a mobile phone with 
WAP functionality. Of course, if only data transmission/ 
reception is required (and not voice), the phone func- 
tionality 24 can be omitted; an example of this is a PDA 
with built-in GSM data-capable functionality whilst an- 
other example is a digital camera (the data-handling 
subsystem) also with built-in GSM data-capable func- 
tionality enabling the upload of digital images from the 
camera to a storage server. 

[0014] Whilst the above description has been given 
with reference to a PLMN based on GSM technology, it 
will be appreciated that many other cellular radio tech- 
nologies exist and can typically provide the same type 
of functionality as described for the GSM PLMN 1 0. 
[001 5] Recently, much interest has been shown in "lo- 
cation-based", "location-dependent", or "location- 
aware" services for mobile users, these being services 
that take account of the current location of the user (or 
other mobile party). The most basic form of this service 
is the emergency location service whereby a user in 
trouble can press a panic button on their mobile phone 
to send an emergency request-for-assistance message 
with their location data appended. Another well known 
location -based service is the provision of traffic and 
route-guiding information to vehicle drivers based on 
their current position. A further known service is a "yel- 
low pages" service where a user can find out about 
amenities (shops, restaurants, theatres, etc.) local to 
their current location. The term "location-aware servic- 
es" will be used herein to refer generically to these and 
similar services where a location dependency exists. 
[0016] Location-aware services all require user loca- 
tion as an input parameter. A number of methods al- 
ready exist for determining the location of a mobile user 
as represented by an associated mobile equipment. Ex- 
ample location -determining methods will now be de- 
scribed with reference to Figures 2 to 5. As will be seen, 
some of these methods result in the user knowing their 
location thereby enabling them to transmit it to a loca- 
tion-aware service they are interested in receiving, 
whilst other of the methods result in the user's location 
becoming known to a network entity from where it can 
be supplied directly to a location -aware service (gener- 
ally only with the consent of the user concerned). It is to 
be understood that additional methods to those illustrat- 
ed in Figures 2 to 5 exist. 



4 

[0017] As well as location determination, Figures 2 to 
5 also illustrate how the mobile entity requests a loca- 
tion-aware service provided by service system 40. In the 
present examples, the request is depicted as being 
5 passed over a cellular mobile network (PLMN 1 0) to the 
service system 40. The PLMN is, for example, similar to 
that depicted in Figure 1 with the service request being 
made using a data-capable bearerservice of the PLMN. 
The service system 40 may be part of the PLMN itself 
10 or connected to it through a data network such as the 
public Internet. It should, however, be understood that 
infrastructure other than a cellular network may alterna- 
tively be used for making the service request 
[0018] The location-determining method illustrated in 
15 Figure 2 uses an inertial positioning system 50 provided 
in the mobile entity 20A, this system 50 determining the 
displacement of the mobile entity from an initial refer- 
ence position. When the mobile entity 20A wishes to in- 
voke a location -aware service, it passes its current po- 
20 sition to the corresponding service system 40 along with 
the service request 51 . This approach avoids the need 
for an infrastructure to provide an external frame of ref- 
erence; however, cost, size and long-term accuracy 
concerns currently make such systems unattractive for 
25 incorporation into mass-market handheld devices. 

[0019] Figure 3 shows two different location-deter- 
mining methods both involving the use of local, fixed- 
position, beacons here shown as infra-red beacons IRD 
though other technologies, such as short-range radio 
30 systems (in particular, "Bluetooth" systems) may equally 
be used. The right hand half of Figure 3 show a number 
of independent beacons 55 that continually transmit 
their individual locations. Mobile entity 20B is arranged 
to pick up the transmissions from a beacon when suffi- 
35 ciently close, thereby establishing its position to the ac- 
curacy of its range of reception. This location data can 
then be appended to a request 59 made by the mobile 
entity 20B to a location -aware service available from 
service system 40. A variation on this arrangement is 
for the beacons 55 to transmit information which whilst 
not directly location data, can be used to look up such 
data (for example, the data may be the Internet home 
page URL of a store housing the beacon 55 concerned, 
this home page giving the store location - or at least 
« identity, thereby enabling look-up of location in a direc- 
tory service). 

[0020] In the left-hand half of Figure 3, the IRB bea- 
cons 54 are all connected to a network that connects to 
a location server 57. The beacons 54 transmit a pres- 
50 ence signal and when mobile entity 20C is sufficiently 
close to a beacon to pick up the presence signal, it re- 
sponds by sending its identity to the beacon. (Thus, in 
this embodiment, both the beacons 54 and mobile entity 
20C can both receive and transmit IR signals whereas 
55 beacons 55 only transmit, and mobile entity 20B only 
receives, I R signals). Upon a beacon 54 receiving a mo- 
bile entity's identity, it sends out a message over network 
56 to location server 57, this message linking the identity 
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of the mobile entity 20C to the location of the relevant 
beacon 54. Now when the mobile entity wishes to invoke 
a location-aware service provided by the service system 
40, since it does not know its location it must include ifs 
identity in the service request 58 and rely on the service s 
system 40 to look up the current location of the mobile 
entity in the location server 57. Because location data 
is personal and potentially very sensitive, the location 
server 57 will generally only supply location data to the 
service system 40 after the latter has produced an au- 10 
thorizing token supplied by the mobile entity 20B in re- 
quest 58. It will be appreciated that whilst service system 
40 is depicted as handling service requests form both 
types of mobile entity 20 B and 20C, separate systems 
40 may be provided for each mobile type (this is likewise 
true in respect of the service systems depicted in Fig- 
ures 4 and 5). 

[0021] Figure 4 depicts several forms of GPS loca- 
tion-determining system. On the left-hand side of Figure 
4, a mobile entity 20D is provided with a standard GPS 
module and is capable of determining the location of en- 
tity 20D by picking up signals from satellites 60. The en- 
tity 20D can then supply this location when requesting, 
in request 61 , a location -aware service from service sys- 
tem 40. 

[0022] The right-hand side of Figure 4 depicts, in re- 
lation to mobile entity 20E, two ways in which assistance 
can be provided to the entity in deriving location from 
GPS satellites. Firstly, the PLMN 10 can be provided 
with fixed GPS receivers 62 that each continuously keep 
track of the satellites 60 visible from the receiver and 
pass information in messages 63 to local mobile entities 
20 E as to where to look for these satellites and estimat- 
ed signal arrival times; this enables the mobile entities 
20E to substantially reduce acquisition time for the sat- 
ellites and increase accuracy of measurement (see "Ge- 
olocation Technology Pinpoints Wireless 911 calls with- 
in 15 Feet" 1-Jul-99 Lucent Technologies, Bell Labs). 
Secondly, as an alternative enhancement, the process- 
ing load on the mobile entity 20E can be reduced and 
encoded jitter removed using the services of network 
entity 64 (in or accessible through PLMN 10). 
[0023] One the mobile unit 20E has determined its lo- 
cation, it can pass this information in request 65 when 
invoking a location-aware service provided by service 
system 40. 

[0024] Figure 5 depicts two general approaches to lo- 
cation determination from signals present in a cellular 
radio infrastructure. First, it can be noted that in general 
both the mobile entity and the network will know the 
identity of the cell in which the mobile entity currently 
resides, this information being provided as part of the 
normal operation of the system. (Although in a system 
such as GSM, the network may only store current loca- 
tion to a resolution of a collection of cells known as a 
"location area", the actual current cell ID will generally 
be derivable from monitoring the signals exchanged be- 
tween the BSC 14 and the mobile entity). Beyond cur- 



rent basic cell ID, it is possible to get a more accurate 
fix by measuring timing and/or directional parameters 
between the mobile entity and multiple BTSs 13, these 
measurement being done either in the network or the 
mobile entity (see, for example, International Applica- 
tion WO 99/04582 that describes various techniques for 
effecting location determination in the mobile and WO 
99/55114 that describes location determination by the 
mobile network in response to requests made by loca- 
tion-aware applications to a mobile location center - 
server- of the mobile network). 

[0025] The left-hand half of Figure 5 depicts the case 
of location determination being done in the mobile entity 
20F by, for example, making Observed Time Difference 
(OTD) measurements with respect to signals from BTSs 
13 and calculating location using a knowledge of BTS 
locations. The location data is subsequently appended 
to a service request 66 sent to service system 40 in re- 
spect of a location-aware service. The calculation load 
on mobile entity 20F could be reduced and the need for 
the mobile to know BTS locations avoided, by having a 
network entity do some of the work. The right-hand half 
of Figure 5 depicts the case of location determination 
being done in the network, for example, by making Tim- 
ing Advance measurements for three BTSs 13 and us- 
ing these measurements to derive location (this deriva- 
tion typically being done in a unit associated with BSC 
14). The resultant location data is passed to a location 
server 67 from where it can be made available to au- 
thorised services. As for the mobile entity 20C in Figure 
3, when the mobile entity 20G of Figure 5 wishes to in- 
voke a location -aware service available on service sys- 
tem 50, it sends a request 69 including an authorisation 
token and its ID (possible embedded in the token) to the 
service system 40; the service system then uses the au- 
thorisation token to obtain the current location of the mo- 
bile entity 20G from the location server 67. 
[0026] In the above examples, where the mobile entity 
is responsible for determining location, this will generally 
be done only at the time the location-aware service is 
being requested. Where location determination is done 
by the infrastructure, it may be practical for systems cov- 
ering only a limited number of users (such as the system 
illustrated in the left-hand half of Figure 2 where a 
number of infrared beacons 54 will cover a generally 
fairly limited) for location-data collection to be done 
whenever a mobile entity is newly detected by an IRB, 
this data being passed to location server 57 where it is 
cached for use when needed. However, for systems 
covering large areas with potentially a large number of 
mobile entities, such as the Figure 5 system, it is more 
efficient to effect location determination as and when 
there is a perceived need to do so; thus, location deter- 
mination may be triggered by the location server 67 in 
response to the service request 68 from the mobile en- 
tity 20G or the mobile entity may, immediately prior to 
making request 68, directly trigger BSC 14 to effect a 
location determination and feed the result to location 
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server 67. 

[0027] Further with respect to the location servers 57, 
67, whilst access authorisation by location-aware serv- 
ices has been described as being through authorisation 
tokens supplied by the mobile entities concerned, other 
authorisation techniques can be used. In particular, a 
location-aware service can be prior authorised with the 
location server in respect of particular mobile entities; in 
this case, each request from the service for location data 
needs only to establish that the request comes from a 
service authorised in respect of the mobile entity for 
which the location data is requested. 
[0028] As already indicated, Figures 2 to 5 depict only 
some examples of how location determination can be 
achieved, there being many other possible combina- 
tions of technology used and where in the system the 
location-determining measurements are made and lo- 
cation is calculated, stored and used Thus, the loca- 
tion-aware service may reside in the mobile entity 
whose location is of interest, in a network-connected 
service system 40 (as illustrated), or even in another 
mobile entity. Furthermore, whilst in the examples of 
Figures 2 to 5, invocation of the location -aware service 
has been by the mobile entity whose location is of inter- 
est, the nature of the location -aware service may be 
such that it is invoked by another party (including, po- 
tentially, the PLMN itself). In this case, unless the invok- 
ing party already knows the location of he mobile entity 
and can pass this information to the location-aware 
service (which may, for example, may be situation 
where the PLMN invokes the service), it is the location- 
aware service that is responsible for obtaining the re- 
quired location data, either by sending a request to the 
mobile entity itself or by requesting the data from a lo- 
cation server. Unless the location server already has the 
needed information in cache, the server proceeds to ob- 
tain the data either by interrogating the mobile entity or 
by triggering infrastructure elements to locate the mo- 
bile. For example, where a location -aware service run- 
ning on service system 40 in Figure 5 needs to find the 
location of mobile 20G, it could be arranged to do so by 
requesting this information from location server 67 
which inturn requests the location data from the relevant 
BSC, the latter then making the necessary determina- 
tion using measurements from BTSs 13. 
[0029] Although in the foregoing, the provision of lo- 
cation data through the mobile radio infrastructure to the 
mobile entity has been treated as a service effected over 
a data-capable bearer channel, it may be expected that 
as location data becomes considered a basic element 
of mobile radio infrastructure services, provision will be 
made in the relevant mobile radio standards for location 
data to be passed over a signalling channel to the mobile 
entity. 

[0030] It is an object of the present invention to pro- 
vide an improved method and system for service deliv- 
ery to mobile users. 



Summary of the Invention 

[0031] According to one aspect of the present inven- 
tion, there is provided a service delivery method com- 
5 prising the steps of: 

qualifying a user as authorised to benefit from an 
instance of a particular service, and storing: 

10 - location data indicative of at least one location 
where service delivery is to be triggered, and 
a service instance element that associates the 
user and the service instance for which the user 
has been qualified; and 

15 

subsequently detecting a location match between 
the location of the user, as indicated by a mobile 
entity associated with the user, and a location indi- 
cated by said location data, and thereupon initiating 
20 delivery to the user of the service instance associ- 
ated with the user by the service instance element. 

[0032] According to another aspect of the present in- 
vention, there is provided a service delivery system 
25 comprising: 

a location description repository for storing location 
data; 

a service-instance-element repository for storing at 
30 least one service instance elements; 

a qualification subsystem for determining whether 
a user qualifies to benefit from an instance of a par- 
ticular service, the qualification subsystem being 
operative, upon determining that a user is so qual- 
35 ified, both to store in the location repository location 
data indicative of at least one location where service 
delivery is to be triggered, and also to store in the 
service-instance-element repository a service in- 
stance element that associates the user and the 
40 service instance for which the user has been qual- 
ified; 

a service execution environment for executing serv- 
ice instances; 

a location match subsystem for detecting a location 
45 match between the location of the user, as indicated 
by a mobile entity associated with the user, and a 
location indicated by said location data; and 
a control arrangement responsive to the location 
subsystem detecting a said location match to initi- 
50 ate execution of the service instance associated 
with the user by the service instance element. 

Brief Description of the Drawings 

55 [0033] A service delivery method and system, both 
embodying the present invention, will now be described, 
by way of non-limiting example, with reference to the 
accompanying diagrammatic drawings, in which: 
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Figure 1 is a diagram of a known communications 
infrastructure usable for transferring voice and data 
to/from a mobile entity; 

Figure 2 is a diagram illustrating one known ap- 
proach to determining the location of a mobile entity, 5 
this approach involving providing the entity with an 
inertial positioning system; 

Figure 3 is a diagram illustrating another known ap- 
proachto determining the location of a mobile entity, 
this approach being based on proximity of the mo- 10 
bile entity to fixed-position local beacons; 
Figure 4 is a diagram illustrating a further known 
approach to determining the location of a mobile en- 
tity, this approach involving the use of GPS satel- 
lites; 15 
Figure 5 is a diagram illustrating a still further ap- 
proach to determining the location of a mobile entity, 
this approach being based on the use of signals 
present in a cellular mobile radio communications 
system; 20 
Figure 6 is a diagram illustrating the main logical 
components of a service delivery method and sys- 
tem embodying the invention; 
Figure 7 is a diagram illustrating a first specific em- 
bodiment of the invention; 25 
Figure 8 is a diagram illustrating a second specific 
embodiment; 

Figure 9 is a diagram illustrating a third specific em- 
bodiment; and 

Figure 10 is a diagram illustrating a fourth specific 30 
embodiment. 



alised embodiment of the service delivery method 
shown in Figure 6. In Figure 6 a user entity 70 is depicted 
which comprises a user and a mobile device through 
which the location of the user can be ascertained (for 
example, a mobile entity 20 such as shown in Figures 
2 to 5). For convenience, the term "user entity" will be 
used both for actions/events involving only the device 
itself and actions/events involving the user acting 
through the mobile device; the reference 70 will be used 
both for the user entity and for the user alone. 

[1] - When the user 70 subscribes to a service or 
buys a product with which a service is associated, 
the service seller, acting through a service factory 
client 71 , causes an executable service instance 76 
to be created by a service factory 72 associated with 
the service. The service instance is an embodiment 
of the behavior associated with the purchased serv- 
ice. The service instance is associated with a set of 
well-defined locations that are of interest to the 
service. These locations are specified in location 
descriptors 74 that either specify locations or polyg- 
onal areas, either as a set of x,y coordinates, or as 
a set of high-level semantic representations such 
as "Lloyds Bank, Bristol" that can be mapped to 
physical locations. Each user has a Service Repos- 
itory 75 to hold the current set of service instances 
76 active for the user's context. The Location De- 
scriptors 74 associated with the service instances 
of the user are held in a Location Descriptor Repos- 
itory 73. 



Best Mode of Carrying Out the Invention 

[0034] Service delivery methods and systems em- 35 
bodying the invention will now be described with refer- 
ence to Figures 6 to 10. The specific embodiments of 
Figures 7 to 1 0 depict a user with a cellular mobile de- 
vice and a mobile infrastructure with a location server 
for providing location data about mobile users; the spe- *o 
cific embodiments shown in Figures 7 to 9 also depict a 
service system 40 connected to the public Internet 39. 
It is to be understood that the present invention is not 
limited to the specifics of the mobile entity location dis- 
covery means or communication infrastructure shown *s 
in the Figures and the generalisations discussed above 
in relation to Figures 1 to 5 regarding these elements 
apply equally to the operational context of the described 
embodiments of the invention. Thus, whilst the service 
system 40 in Figures 7 to 9 is shown as connected to 
the public Internet, it could be connected to a GPRS net- 
work 1 7 or to another fixed data network interfacing di- 
rectly or indirectly with the network 17 or network 39. 
Furthermore, communication between the user's mobile 
entity and a service system can be via a communication 55 
infrastructure that does not use cellular radio; for exam- 
ple, a short-range wireless system could be used. 
[0035] Consideration will f irst be given to the gener- 



al - The newly created service instance 76 and an 
initial set of one or more location descriptors 74 to 
be applied to the service, are downloaded respec- 
tively to the Service Repository 75 and Location De- 
scriptor Repository 73 of the user. The service re- 
mains dormant until the location of the user entity 
70 matches one of the locations defined by the Lo- 
cation Descriptors defined for the service. 

[3] - The physical location of the user entity 70 is 
obtained by a location source 77 in any suitable 
manner and passed on a periodic basis to a Loca- 
tion Comparator Engine 78. 

[4] - The Location Comparator Engine 78 compares 
the current location of entity 70 with the set of active 
Location Descriptors 74. If a match is found, a trig- 
ger is sent to a Service Execution Environment 79, 
this trigger identifying the service instance to be ex- 
ecuted (for example, by combination of user ID and 
location, or by a service instance identifier held with 
the matched Location Descriptor) 

[5] - the Service Execution Environment 79 loads 
the appropriate service instance 76 and executes 
it, passing in the current location if required. The 
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service may be one that once triggered, runs to 
completion regardless of subsequent changes in lo- 
cation, or one that only functions whilst the location 
matches a location descriptor. In this lattercase, lo- 
cation samples are taken at intervals and the serv- 
ice only continues to run for as long as the current 
location matches the Location Descriptors of the 
service. 

[6] - The service can be enabled to specify the fre- 
quency of location updates it requires, and also 
modify the set of Location Descriptors 74 to be ap- 
plied. 

[0036] The physical location of the functional entities 
71 , 72, 73, 75, 77, 78 and 79 depends on the architec- 
ture of the network infrastructure used to inter-commu- 
nicate the entities and the capabilities of the mobile de- 
vice of user entity 70. Thus, whilst the Service Factory 
72 will generally be located in the network infrastructure, 
each of the other entities could be located either on the 
mobile device or in the network. 

[0037] A possible service delivery scenario is as fol- 
lows. A customer buys an airline flight ticket. A service 
instance 76 is instantiated by the airline to identify the 
specific purchasing transaction, so that the behavior of 
the service instance can be made dependent on char- 
acteristics of the transaction. A description of the loca- 
tion trigger point(s) of the service is stored either in the 
user's mobile device (e.g. a cell-phone device) or in the 
cellular radio infrastructure. Assume that a trigger point 
is the airport. When the customer arrives at the airport, 
the location of the mobile device as determined by the 
cellular radio infrastructure matches the trigger point of 
the service. The service instance is now activated, can 
welcome the customer by name, politely ask them to 
check in, invite and direct the customerto airline lounge 
if the customers ticket is of the appropriate type, and 
finally remind the customer to leave the lounge when 
the flight is boarding. 

[0038] In the Figure 6 embodiment, a full executable 
service instance is created by the service factory. This 
is particularly useful where the service execution envi- 
ronment is either the mobile device or another system 
which does not have large resources or continual net- 
work access. An alternative approach is to store in- 
stance customization data that can be used to custom- 
ize generalized service code that is available to the serv- 
ice execution environment either because the latter has 
resources to store such code or can access the code 
across a network connection. 

[0039] Thus, in general terms, the service factory, 
once it is satisfied that the user has qualified for the serv- 
ice (for example, by having paid or by having appropri- 
ate attributes), generates a service instance element 
that associates the user with an instance of the service 
for which the user has been qualified. The service in- 
stance element can be a full executable code version of 



the service as described above in relation to Figure 6, 
customization data customizing a generalized service 
to the user, or even just an indicator that the user is en- 
titled to the benefits of a service instance which is not 

5 otherwise subject to customization. 

[0040] A number of different ways can be used by the 
service instance element to associate the user and the 
service instance for which the user has been qualified.. 
One way is to have the service instance element contain 

10 an identifier of the user, the instance element either itself 
including the instance executable or including a refer- 
ence to the latter; in this case, the location trigger proc- 
ess results in the user identifier being produced for 
matching up with the service instance element (note that 

15 jf multiple service instance elements are stored for the 
same user, additional information such as triggering lo- 
cation, may be required to distinguish between the serv- 
ice instance elements). Another way is to include a serv- 
ice instance identifier in the service instance element, 

20 this identifier also being associated with the user (for 
example, by being known to the user entity) and being 
produced by the location trigger process for matching 
with the service instance element. A third way of having 
the service instance element associate a user with a 

25 particular service instance is to store the service in- 
stance element in the user entity or other user-dedicated 
entity. 

[0041] With regard to the location triggering process, 
it will be appreciated that this can be implemented in 

30 many ways. For example, the location descriptors can 
be stored in a service system containing the service ex- 
ecution environment, the user's current location being 
provided to the service system by a location server 
(such as server 57 of Figure 3 or server 67 of PLMN 10 

35 of Figure 5) or by the user entity 70 itself (the entity 70 
having discovered its location by any of the methods de- 
picted in Figures 2 to 5, for example). Alternatively, the 
location descriptors could be stored in a location server 
57 or 67 with location matching also being effected in 

40 the server. Another possibility is to store the location de- 
scriptors in the user entity 70 itself, the latter discovering 
its location by a method of Figures 2 to 5 and effecting 
the location matching process itself. 
[0042] Specific example embodiments will now be de- 

45 scribed with reference to Figures 7 to 1 0. 

[0043] In the Figure 7 embodiment, the service factory 
has loaded a service instance element (SIE) 80 into a 
database 75 of a service delivery system 40 and a cor- 
responding location descriptor 74 into a repository 73 

so associated with location server 67 of PLMN 1 0. The SIE 
80 comprises, in this example, a user identifier (user ID) 
and user-specific customization data. The location de- 
scriptor 74 also includes the user ID and the location 
server 67 of PLMN understands which PLMN subscriber 

55 is identified by this user ID (conveniently, the user ID 
can be the IMSI associated with the user). Service sys- 
tem 40 comprises, as well as database 75, a program 
database 81 holding the generic program code for the 
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services to be delivered by the system, a service exe- 
cution environment 78, a service loader 82 for loading 
the correct service program and customization data to 
provide a required service instance, and interface 41 for 
interfacing the service system with a communication in- 
frastructure (here shown as internet 39). 
[0044] The user's mobile device is a cellular- radio mo- 
bile entity 20 such as described with reference to Figure 
1 and is capable of communicating with the service sys- 
tem 40 via a data-capable bearer service of PLMN 10 
and internet 39. When the mobile entity is in a switched- 
on state, location server 67 of PLMN 10 is capable of 
determining the location of the mobile entity. 
[0045] In operation, upon the mobile entity 20 being 
detected by location server 67 as at a location matching 
a location descriptor 74 associated with the user, a lo- 
cation match trigger (including user ID and possibly also 
user location) Is passed from the location server 67 to 
the service loader 82 of the service system 40 (see ar- 
row 85). The service loader uses the user ID (and pos- 
sibly also the user location) to identify the corresponding 
SIE 80. The SIE 80 identifies the service program to be 
executed and service loader 82 causes the relevant pro- 
gram to be loaded into the service execution environ- 
ment along with the customization data contained in the 
SIE 80 in order to create and run the service instance 
for which the user has been prior authorized. Execution 
of the service instance will generally (but not necessar- 
ily) involve communication between the service system 
and the user's mobile entity 20, for example using a da- 
ta-capable bearer service of PLMN 10 (see arrow 86). 
[0046] The Figure 8 embodiment is similar to that of 
Figure 7 except that now the location descriptors 74 are 
stored in mobile entity 20, each with an associated serv- 
ice instance identifier (SI ID), and the SIEs 80 stored in 
database 75 each include a corresponding SI ID. Loca- 
tion matching between the location descriptors and the 
user's current location (as identified to the entity 20 by 
location server 67 or discovered in some other way) is 
done in the mobile entity 20. When a match is detected, 
the SI ID associated with the matched location is passed 
to the service loader 82 (see arrow 87) which looks up 
the corresponding SIE 80 in database 75 and then over- 
sees running of the appropriate service instance. If re- 
quired, the SIE 80 can include both the user ID and the 
locations where the service instance is permitted to be 
triggered; the service loader can then be arranged to 
confirm (and possibly even require authentication of) the 
user's identity and the origin of the user's location fix 
(the service instance may, for example, require that only 
location fixes by location server 67 will be trusted, in 
which case the mobile entity 20 can be required to pro- 
vide digitally-signed location data from the server 67). 
[0047] In the Figure 9 embodiment, the location de- 
scriptors 74 are again stored in the mobile entity 20 
where location matching is effected. However, now the 
SIE 80 is also stored in the mobile entity 20 and takes 
the form of a service token that can be used to claim 



service instance delivery from a service system 40. The 
service token is associated with the user by virtue of be- 
ing stored in the mobile entity 20 and includes data iden- 
tifying the service to be provided by service system 40 

5 and any service customization data; advantageously, 
the service token also includes address (and password) 
details for contacting the service system. In operation, 
upon a location match being detected, the mobile entity 
transits the service token, via a data-capable bearer 

10 service of PLMN 1 0 and the internet 39, to the service 
system. At the service system, the token is passed to 
an authentication and service execution subsystem 83 
where it is used to instantiate and run the required serv- 
ice instance. 

15 [0048] Preferably the service token includes the us- 
er's identity and is digitally signed by the service factory 
(with a corresponding certificate being included in the 
token). In this case, the sub-system 83 can both: 

20 - check that the service token originates from a serv- 
ice factory for which it is willing to provide service 
delivery (this check involves checking the identity 
of the signing party with the certification authority in 
standard manner); and 

25 - check that the party sending the token is the same 
as the party identified in the token (the authenticity 
of which is guaranteed by the digital signature). 
Checking the sending party's identity is done using 
a challenge / response mechanism by which the 

30 service system 40 sends an item of data to the mo- 
bile entity and asks it to return it signed/encrypted 
under its private key (it being assumed that the mo- 
bile entity is provided with a public key / private key 
pair that are associated with the user). This enables 

35 the service system to check the identity of the user 
(with the user's certificate authority) and thus check 
whether the user is the same party as identified in 
the token. 

40 [0049] Of course, since the basic challenge/response 
mechanism is something that is normally done between 
the system 40 and the mobile entity 20 without involve- 
ment of the user, the mechanism does not guard against 
the mobile entity having been stolen. As an added pre- 

45 caution, therefore, the user authentication process pref- 
erably further includes asking for the user to input a PIN 
number, this latter being known to the system 40 (such 
as by having been included in the token, possibly en- 
crypted in a manner enabling only the service system 

so 40 to decrypt it - for example, the service factory en- 
crypts the PIN using the public key of the service system 
40). 

[0050] It will be appreciated that the same authenti- 
cation process can equally be applied in full or in part to 
55 the case where the service token is replaced by a fully 
executable service instance code. 
[0051] In the Figure 10 embodiment the location de- 
scriptors 74 are again stored in the mobile entity 20 
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where location matching is effected. However, now the 
SIE 80 comprises the full service instance executable 
76 stored in the mobile entity 20 and intended to execute 
in the mobile entity when a location match is detected. 
No external interaction with a pre-authorised service el- 
ement is required. Of course, external service interac- 
tions can be effected during the course of service exe- 
cution (though not shown in Figure 10). As already not- 
ed, the current location of the mobile entity can be pro- 
vided by means other than the location server 67 of 
PLMN 1 0, for example by a built-in GPS system or from 
local location beacons, and in this case, wide-area con- 
nectivity is not required for mobile entity 20. 

Variants 

[0052] It will be appreciated that many variants are 
possible with respect to the above described embodi- 
ments with features described in relation to one embod- 
iment also being adaptable for use with other of the em- 
bodiments. Thus, for example, the authentication fea- 
tures (digital signing of SIE 80 to check origin, user au- 
thentication through challenge/response mechanism, 
use of PIN) described above in relation to the Figure 9 
embodiment can also be used with the other embodi- 
ments. For example, where the SIE 80 is distributed by 
the service factory to a device or system under different 
control, it will generally be a good practice to have the 
SIE digitally signed by the service factory so as to enable 
the final service delivery system (system 40 in Figures 
7 to 9) to check the origin of the SIE 80. Again, checking 
the identity of the user requesting service execution will 
often also be prudent, using a challenge/response 
mechanism and/or PIN input. 

[0053] As noted above, the mobile entity 20 need not 
have wide-area connectivity. For example, communica- 
tion with service system 40 could be through a short 
range wireless link (for example, an infra-red link or a 
Bluetooth radio connection). In fact, as already indicated 
with respect to the Figure 10 embodiment, the mobile 
entity 20 need not have any external communication ca- 
pability other than to enable it to determine its location. 
[0054] The location descriptors and service instances 
elements can be stored by user, by service to be deliv- 
ered, or in any other suitable distribution. For example, 
where different service systems 40 are used for different 
services in the embodiments of Figures 7 and 8 embod- 
iments, then the database 75 of each service system 40 
will store SIEs 80 relating to different users but the same 
service. 

[0055] A service instance element can be arranged to 
specify a particular number of times (including only 
once) that the associated service instance can be run, 
each running of the service instance decrementing this 
count (or incrementing a count of the number of times 
the instance has been run). 



Claims 

1 . A service delivery method comprising the steps of: 

5 - qualifying a user as authorised to benefit from 
an instance of a particular service, and storing: 

location data indicative of at least one lo- 
cation where service delivery is to be trig- 
10 gered, and 

a service instance element that associates 
the user and the service instance for which 
the user has been qualified; and 

15 - subsequently detecting a location match be- 
tween the location of the user, as indicated by 
a mobile entity associated with the user, and a 
location indicated by said location data, and 
thereupon initiating delivery to the user of the 
20 service instance associated with the user by the 

service instance element. 

2. A method according to claim 1 , wherein the service 
instance element is associated with the user by a 

25 user identifier included in the element, and with the 
service instance by either comprising code for im- 
plementing the instance or including a reference to 
such code, the user's mobile entity directly or indi- 
rectly supplying this user identifier for service deliv- 
30 ery to be effected. 

3. A method according to claim 1 , wherein the service 
instance element is associated with the user by a 
service-instance identifier known to the user or the 

35 user's mobile entity, the service instance element 
either comprising code for implementing the service 
instance or including a reference to such code, the 
user's mobile entity directly or indirectly supplying 
this service-instance identifier for service delivery 

40 to be effected. 

4. A method according to claim 1 , wherein the service 
instance element is stored in a service provider sys- 
tem with which the user's mobile entity can commu- 

45 nicate through a communications infrastructure, 
and wherein the location data is stored in one of: 

a location server of the communications infra- 
structure, 
so - the mobile entity, 

the service provider system, 

where it is compared against the current location of 
the mobile entity as provided by one of: 

55 

a location server associated with the communi- 
cations infrastructure, 

location discovery means of the mobile entity; 
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in order to detect a said location match; the detec- 
tion of a location match causing the service provider 
system to identify the service instance to be deliv- 
ered by matching a said identifier provided directly 
or indirectly by the user's mobile entity with said 
service instance element. 

5. A method according to claim 1 , wherein the service 
instance element associates the user and service 
instance by virtue of the service instance element 
being stored in the user's mobile entity and either 
comprising code for implementing the service in- 
stance or including a reference to such code. 

6. A method according to claim 5, wherein the service 
instance element is a token which upon the use'sr 
mobile entity determining or being informed of a 
said location match, is passed by the mobile entity 
over a communications infrastructure lo a service 
provider system where it is used to initiate service 
provision to the user. 

7. A method according to claim 6 ; wherein the token 
includes user identity data and is digitally-signed by 
the party that carried out the qualification step 
whereby the service provider system can check the 
authenticity of the data in the token, the user mobile 
entity having an associated public-key / private-key 
pair and being required by the service provider sys- 
tem to authenticate its identity by using its private 
key to sign and return data proposed by the service 
provider system. 

8. A method according to any one of the preceding 
claims, wherein the service instance element in- 
cludes customisation data customising a generic 
service to said service instance. 

9. A method according to any one of the preceding 
claims, wherein service delivery is conditional upon 
the user inputting a personal identification code. 

10. A method according to any one of the preceding 
claims, wherein service delivery only continues 
whilst the user's current location matches with a lo- 
cation indicated by the location data. 

11. A method according to any one of claims 1 to 9, 
wherein once initiated, service delivery is continued 
until completion. 

12. A method according to any one of the preceding 
claims, wherein the service instance modifies the 
location data as part of service delivery. 

13. A method according to any one of the preceding 
claims, wherein the location data is indicative of 
multiple locations. 



14. A method according to any one of the preceding 
claims, wherein multiple service instance elements 
associated with different service instances to be de- 
livered to the same user, are stored in a common 

5 repository. 

15. A method according to any one of the preceding 
claims, wherein the service instance element is 
passed by the party that carries out the qualification 

10 step to the user or to a third-party, the service in- 
stance element being digitally signed by the party 
that carries out the qualification step whereby to en- 
able an eventual service deliverer to check the ori- 
gin and authenticity of the service instance element. 

15 

16. A method according to any one of the preceding 
claims, wherein the current user location is provided 
by a trusted location service provider and Is digital- 
ly-signed by the latter. 

20 

17. A method according to any one of the preceding 
claims, wherein said service instance element 
specifies a particular number of times (including on- 
ly once) that the associated service instance can be 

25 run. 

18. A service delivery system comprising: 

a location description repository for storing lo- 

30 cation data; 

a service-instance-eiement repository for stor- 
ing at least one service instance elements; 
a qualification subsystem for determining 
whether a user qualifies to benefit from an »n- 

35 stance of a particular service, the qualification 

subsystem being operative, upon determining 
that a user is so qualified, both to store in the 
location repository location data indicative of at 
least one location where service delivery is to 

40 be triggered, and also to store in the service- 

instance-element repository a service instance 
element that associates the user and the serv- 
ice instance for which the user has been qual- 
ified; 

45 - a service execution environment for executing 
service Instances; 

a location match subsystem for detecting a lo- 
cation match between the location of the user, 
as indicated by a mobile entity associated with 
so the user, and a location indicated by said loca- 

tion data; and 

a control arrangement responsive to the loca- 
tion subsystem detecting a said location match 
to initiate execution of the service instance as- 
55 sociated with the user by the service instance 

element. 

19. A system according to claim 18, wherein the loca- 
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tion description repository is incorporated in said 
mobile entity associated with the user. 

20. A system according to claim 18, wherein the serv- 
ice-instance-element repository is incorporated in 5 
said mobile entity associated with the user. 

21 . A system according to claim 20, wherein the service 
execution environment is incorporated in said mo- 
bile entity associated with the user, the service in- 10 
stance element taking the form of service instance 
code to be run in the execution environment.. 

22. A system according to claim 20, wherein the mobile 
entity and service execution environment can inter- *5 
communicate via a wireless infrastructure at least 
when the mobile entity is positioned to give rise to 

a location match, the service instance element tak- 
ing the form of a service token which the mobile en- 
tity is operative to pass to the execution environ- 20 
ment upon occurrence of a said location match in 
order to trigger execution of the service instance. 
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